Subject: Flow Control curve ball...

From: Paul Brittain <[email-masked]>
Date: Wed, 14 Dec 94 13:17:00 GMT

A very last minute thought on Flow Control...

Currently the Flow Control flags may be piggy-backed on almost all message 
types, not just on INFOFRAME or DGRMFRAME messages.  This has the 
unfortunate effect of making it difficult to architect a separate 'data 
forwarder process' for each circuit that handles only the golden path data 
traffic as it cannot have sole responsibility for Flow Control.

I'll confess an interest in this - we do have such a data forwarder and 
would like to be able to achieve the clean functional separation of putting 
all Flow Control responsibility in this process.  I don't believe this would 
be a performance problem even though it would mean that the grant of the 
initial window would flow as an independent flow control message.  Once into 
data flow (I or UI frames) there would be no difference to the Flow Control 
mechanism.

We believe this would be a significant improvement on the architectural 
cleanliness of DLSw, but recognise that it is very much a last minute 
thought for V1 (though it actually requires only relatively little change to 
the document - basically just change the list of permitted frames for Flow 
Control piggybacking and mandate that a RESTART_DL implies either a Reset 
Window or reverts to the initial state).

Is there any interest in doing this for V1 (I'm willing to do the 
appropriate wordsmithing for Alan), or should we consider it in V2 instead?

Paul Brittain
Data Connection

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Wed, 14 Dec 94 16:38:26 PST

Hi Paul,
I just want to bring to your attention the following issues to understand
this a little further and explore the ramifications it has on the 
rest of the ckt setup logic.
	- I think IPM flies with an INFO header(16 bytes).
	  And as we all know it is not enough to resolve the circuit id.
	  The first IPM cannot flow until the ckt is established
	  or we need to change IPM to carry the CONTROL header (76 bytes)
	- Every ckt init would generate an additional IPM
	  in both directions to just exchange the inital grants.
	  That is 2 additional frames for every ckt init,
	  which is not bad.
	- We need to be able to accomodate more than a few
	  XID exchanges to happen without an additional
	  IPM. This mandates that the default initial
	  window size to be atleast > no of frames 
				      to establish ckt + 
				      no of possible XID frames.

	/pandian

-- 
G. Pandian             		+ Gnanaprakasam Pandian      +
Cisco Systems, Inc.    		+ Software Engineer          +           
190, W. Tasman Drive, Bldg E   	+ Phone : (408)526-7684      +
San Jose               		+ FAX   : (408)526-8959      +
CA 95134               		+ E-mail: [email-masked] +